1. Field of the Invention
The present application relates to logic designs for programmable logic devices (PLDs), and specifically to a modular design method for PLDs.
2. Description of the Related Art
A programmable logic device, such as a field programmable gate array (FPGA), is user-programmed to implement logic designs. In a typical architecture, an FPGA includes an array of configurable logic blocks (CLBS) surrounded by programmable input/output blocks (IOBs). The CLBs and IOBs are interconnected by a hierarchy of programmable routing resources. These CLBs, IOBs, and programmable routing resources are customized by loading a configuration bitstream into the FPGA. This configuration bitstream is generated using software tools.
PLDs having over a million gates are becoming increasingly common. With this increase in the number of gates, there is a corresponding pressure to utilize fully the chip""s resources to provide yet more complex logic functionality. Designing the logic for such chips is difficult for one designer to manage. A final logic design (referenced herein as the top-level design) for a million-gate gate PLD may include many logic pieces (referenced herein as modules). Designing these modules sequentially might take one designer a whole year. Even assigning multiple designers to design specific modules will later require combining these modules. This combining process is quite time consuming for the following reasons.
Software is typically structured to have a main program and multiple subroutines for implementing blocks of code referenced in the main program. If the software is complex, multiple people generally write the various subroutines. The main program and subroutines can be written in any order. When complete, the main program calls the subroutines. Of importance, these subroutines are executed as specified regardless of which subroutine was written first.
However, whereas software routines can be stored sequentially in a computer""s memory space, modules to be implemented in a PLD require physical space in the PLD and often must have specific shapes. For example, one piece of logic may require a tall vertical column while another piece may require a rectangular array. Another piece of logic may need to make use of specific resources located in only one part of the PLD.
Therefore, if the method used in writing software were used directly in logic design, the modules would conflict with each other and the resources of the device would not be used optimally. Moreover, prior art PLD design flows copy verbatim or directly reference a module in the top-level design. This process undesirably limits a designer""s ability to modify the module at a later point in time.
For these reasons, a need arises for a method (1) allowing logic designers to work in parallel on modules of a top-level logic design and (2) facilitating the combination of these modules to implement the logic design on a PLD.
In accordance with the present invention, logic designers are able to partition a top-level logic design for a PLD into modules and implement any module independently from other modules. Modules are mapped, placed, and routed using selected information derived at the time the top-level logic design is partitioned. (The step of mapping consists of grouping elements of a design into units that can be implemented by a single piece of hardware in the PLD, for example a configurable logic block (CLB) in an FPGA. The step of placing consists of assigning each of these units to a specific piece of hardware, such as a specific CLB. The step of routing consists of designating conductive interconnect lines in the PLD to carry signals from one unit to another as required by the design. There are known algorithms for performing each of these steps.) Finally, the modules are integrated into the top-level logic design using a xe2x80x9cguidedxe2x80x9d design process.
This guided design process is in contrast to merely copying verbatim the information into the top-level design. Using a verbatim copy would introduce inflexibility into the design process. Specifically, merely copying the information into the top-level design would significantly increase the probability that resource contention will occur and/or timing specifications will not be met, thereby resulting in top-level design failure.
In the present invention, information generated during partitioning of the top-level design and implementation of the module is used to guide implementation of the associated logic in the top-level design, thereby ensuring a high probability of top-level design success. Specifically, in one example, information provided by the implemented modules is used in the mapping stage to ensure that any top-level constraints that might need to be pushed into module implementations are correctly processed. This same information is also used in the placing and routing stage, thereby enabling the place and route tools to perform certain optimizations. For example, common signals going to different modules can be identified, thereby allowing the map, place, and route tools to operate faster. Common signal identification and other tool optimizations can significantly increase the performance and quality of the resulting top-level design.
If the space for each module has been budgeted correctly, one module""s implementation is independent from any other module""s implementation, and the implementation of all modules can proceed in any order or in parallel. Additionally, integration of the modules into the top-level design can be done in any order. Further, later changes or modifications to a design typically affect only a few modules, leaving other modules unaffected, and greatly decreasing the time required for a designer to make the changes. Therefore, compared to prior art processes, the present invention significantly reduces the time to production of the final logic design and provides designers with optimal flexibility in implementing the modules.
Three Basic Phases
In accordance with the present invention, modular design flow includes three basic phases: the initial design phase, the active module phase, and the assembly phase.
Initial Design Phase
The initial design phase, which includes an initial budgeting stage, divides the top-level design into a plurality of unelaborated modules, determines the size and location on-chip (i.e. range) of each module, and defines the input/output (i.e. port) nets for each module. To perform these functions, a ngdbuild tool is run using the electronic design interchange format (EDIF) and netlist constraints (NCF) files to generate top-level native generic object (NGO) and native generic database (NGD) files. A constraints editor tool is run on the top-level NGD file to generate a top-level user constraints file (UCF). The ngdbuild tool is run on the top-level UCF and NGO files to create annotated constraints in the top-level NGD file. Annotation consists of merging constraints from one file into another file. In this case, constraints in the UCF file are copied into respective locations in the NGD file. A floorplanner tool loads (i.e. reads) the top-level NGD and UCF files. The floorplanner tool is then used by the designer to create position and range (size and shape) constraints for each module, and locate top-level logic as well as module ports and any associated constrained pseudo logic (explained in the following paragraph). The resulting constraints are written out to the top-level UCF file.
In accordance with the present invention, each module is assigned a shape and size, preferably by displaying the PLD on a computer monitor and generating a rectangle to represent the shape and size of the PLD region to be occupied by the module. In one embodiment, the position of the module is defined as the location of the center of this rectangle. Then module ports are determined. Module ports provide module input/output signals. Ports may be connected to input/output blocks (IOBs), global logic, or other module ports. A port on one module that connects to a port on another module will be represented by two independent pieces of logic, referenced herein as pseudo logic. In the present invention, pseudo logic is temporary logic that facilitates connection of module ports to one another. Pseudo logic manually placed in a specific location by the user is called xe2x80x9cconstrainedxe2x80x9d pseudo logic, whereas pseudo logic generated by the mapper and not modified by the user is called xe2x80x9cunconstrainedxe2x80x9d pseudo logic. In one embodiment, the two pieces of pseudo logic are placed between modules approximately along a line between the two ports.
To ensure correct placement of a module relative to other objects in the top-level design, a plurality of xe2x80x9crubber bandsxe2x80x9d are connected between a predetermined point in the module (in one embodiment, its center) and its associated IOBs and constrained pseudo logic. In the present invention, the ports for a module are located within the module but generate or receive signals from outside the boundary established for the module. The pseudo logic or IOBs are outside the module and indicate where the port signals go to or come from. Because pseudo logic is not used in the assembly phase, in one embodiment, module-to-module pseudo logic for one module can be located inside the boundary established for another module. In this manner, modules can abut one another, thereby reducing the area needed to implement the final design.
As a last step in the Initial Design Phase, a physically implemented modules (PIM) directory is created in a centralized location. This centralized location, called a Physically Implemented Module (PIM) directory, is created specifically for modular assembly. This PIM directory is a writable directory accessible to all module designers.
Active Module Stages
The active module phase, which independently implements each module, includes the following stages: the module build stage, the module map stage, the module place and route stage, the module floorplan stage (if needed), the module back annotation stage, and the module publishing stage.
In the module build stage, the top-level user constraints (UCF) file is copied into a module directory, thereby creating a module-relative top-level UCF file. A module netlist is created using a standard HDL editor. The module is defined by a module level EDIF file and a module level netlist constraints file (NCF). The ngdbuild tool is run on the module level EDIF and NCF files as well as the module-relative top-level UCF file and the top-level NGO file to generate a module-level NGO file and a module-relative top-level NGD file. The constraints editor tool is run on the module-relative top-level NGD file to add module-specific constraints to the module-relative top-level UCF file. Finally, the ngdbuild tool is run on the module-level NGO file and the top-level UCF file to fully annotate the module-relative top-level UCF constraints into the module-relative top-level NGD file.
In the module map stage, a mapper tool is run on the module-relative, top-level NGD file. If any unconnected ports are identified, then the mapper tool adds unconstrained pseudo logic to those ports. After the addition of unconstrained pseudo logic, module-relative top-level netlist circuit description (NCD) and netlist generic mapping (NGM) files are generated. At the end of this module map stage, all logic elements of the module are assigned to specific physical PLD elements that implement logic functions.
In the module place and route (PAR) stage, a PAR tool, used in a standard manner, determines the placement for the unconstrained pseudo logic and then for the logic elements of the module in the PLD. After placement of the unconstrained pseudo logic and module logic, the PAR tool apportions the appropriate routing resources for all logic (i.e., constrained pseudo logic, unconstrained pseudo logic, and module logic). If the implementation of the module is not correct or fails to meet timing requirements, then the designer first runs the floorplanner tool to directly place the unconstrained pseudo logic and subsequently runs the floorplanner tool to place the module logic. After floorplanning, the design flow returns to the module map stage. Once the implementation of the module is correct, then the design flow proceeds to the module back annotation stage. In the back annotation stage, simulation can be done either with the top-level design as context or independent of the top-level design.
The module level NGO file as well as the module-relative top-level NGM and NCD files (all in the module directory) are published to the PIM directory. In one embodiment, all module-relative top-level files are renamed to module level files in the PIM directory. In the present invention, the active module phase is performed for each module.
Assembly Phase
The assembly phase implements the top-level design while referencing certain module xe2x80x9cguidexe2x80x9d files. The term xe2x80x9cguidexe2x80x9d in the present invention refers to instructions that provide sufficient information for a process to quickly recreate the exact mapping, placement and routing of a module into a target design. In the final implementation stage, the ngdbuild tool is run on the top-level UCF file with a path to the PIM directory. Specifically, the module level NGO files for the modules are accessed from the PIM directory to create a new top-level NGD file. The constraints editor tool can optionally be run at this point to apply timing constraints to the top-level NGD file or modify existing timing constraints. The mapper tool is run on this fully instantiated NGD file using the module level NCD files in the PIM directory as guides, thereby generating fully elaborated top-level NCD and NGM files. The PAR tool is run on the top-level NCD file, again using the module level NCD files in the PIM directory as guides. If the top-level design is incorrect or fails to meet timing constraints, then the designer can manually designate the appropriate tool for correction. Mapping, placing, and routing are performed again, as necessary. If the top-level design is correct, then back annotation can be run to simulate the fully implemented top-level design.